前言

最近在學習 Kubernetes 叢集管理的時候，我對 Scheduler 這個核心元件特別有興趣。平常我們大多數人使用的都是預設的 scheduler（default-scheduler），那我就想：為什麼要有「scheduler profiles」這種東西？為什麼還要有一堆「extension points」可以掛 plugin？

這篇文章我就整理一下自己研究的心得，並且用一些實際場景來解釋：如果只靠預設的 scheduler，我們會遇到什麼限制？為什麼企業級應用常常需要「客製化調度」？最後我會用一個 GPU 模擬的案例來收尾，解釋在 AI/HPC 場景下，scheduler profiles 可以帶來什麼價值。

Kubernetes Scheduler 的運作流程

Kubernetes Scheduler 的任務很單純：把一個等待中的 Pod 指派到最合適的 Node 上。但在這個流程裡，其實有很多步驟，K8s 開放了所謂 extension points 讓我們可以「插入自己的邏輯」。

調度流程大致如下：

這些 extension points 就是 plugin 可以發揮的地方。透過 scheduler profiles，我們可以組合不同的 plugin，甚至在同一個叢集中啟用多個 scheduler profiles，針對不同 workload 使用不同邏輯。

不同 Extension Points 的應用場景

1. QueueSort – 先排隊的人不一定先上車

場景：一個 multi-tenant cluster，同時有高優先權的生產工作（production workloads），還有低優先權的測試工作（best-effort jobs）。
解法：QueueSort plugin 可以讓 scheduler 先挑高優先權的 Pod，避免測試工作佔滿資源。

2. PreFilter – 節省時間的「快速檢查」

場景：AI 團隊要跑一個需要 4 張 GPU 的工作，但叢集裡根本沒有任何一台機器有 4 張空閒的 GPU。
預設 scheduler 的問題：它還是會一台一台 Node 去檢查，最後才告訴你失敗。
解法：PreFilter plugin 可以在一開始就檢查叢集狀況，如果根本不可能排程成功，直接快速回報錯誤，使用者不必白白等待。

3. Filter – 選出符合條件的 Node

場景：你的應用只能跑在特定可用區（zone），或者必須在有 SSD 磁碟的 Node 上。
解法：Filter plugin 可以針對 Node label 做檢查，把不符合條件的 Node 直接排除。

4. PostFilter – 找不到資源怎麼辦？

場景：一個高優先權的 Pod 需要跑，但叢集裡已經被低優先權的工作塞滿了。
解法：PostFilter plugin 可以觸發 preemption，把低優先權的 Pod 踢掉，騰出空間。

5. PreScore + Score – 聰明的打分機制

場景：叢集裡有很多 Node，你想讓工作平均分散，避免某台機器 CPU 過熱。
解法：在 PreScore 階段先蒐集 metrics，然後在 Score 階段給低 CPU 使用率的 Node 更高分，達到負載平衡。

6. Reserve + Permit – 幫忙「團體訂位」

場景：AI Training job 需要一次啟動 8 個 Pod，每個 Pod 各拿 1 張 GPU。如果只有 5 張 GPU，啟動就沒意義。
解法：Reserve + Permit plugin 可以暫時鎖定資源，等到湊齊所有 Pod 一起排程，再一次綁定，避免浪費。

7. Bind – 接入外部系統

場景：公司內部已經有一套資源調度系統，決定 Pod 應該落在哪台機器。
解法：Bind plugin 可以改寫預設的綁定流程，在真正綁定前去呼叫外部 API 做確認。

8. PostBind – 調度後的審計

場景：需要記錄每一次 Pod → Node 的 mapping，方便之後做合規或成本分析。
解法：PostBind plugin 可以在綁定後，把事件送到 Prometheus、ElasticSearch 或外部審計系統。

Scheduler Profiles 的威力

以上的 plugin 不需要同時塞在同一個 scheduler 裡。我們可以透過 profiles 把不同的 plugin 組合成不同「調度風格」。

範例：

profiles:
- schedulerName: high-priority-scheduler
  plugins:
    queueSort:
      enabled:
      - name: PrioritySort
    score:
      enabled:
      - name: LowCPULoad

- schedulerName: gpu-scheduler
  plugins:
    preFilter:
      enabled:
      - name: GpuPreCheck
    filter:
      enabled:
      - name: GpuNodeOnly

Pod 只要在 spec.schedulerName 指定，就能選擇哪個 profile：

spec:
  schedulerName: gpu-scheduler

這讓同一個叢集可以同時支援「一般業務」與「特殊需求」的工作。

GPU 模擬的案例：為什麼需要 PreFilter？

這裡我拿一個實際問題來舉例：假設我要跑一個 需要 2 張 A100 GPU 的模擬工作。

如果只靠預設 scheduler：

• 它會逐一檢查 Node，看有沒有至少 2 張 GPU 可用。
• 如果整個叢集都沒有符合的 Node，它會卡很久才報錯，甚至進入 backoff。

如果有 PreFilter plugin：

• 在調度前就檢查叢集：根本沒有任何 Node 符合條件 → 立即回報錯誤。
• 還可以加入更細緻的檢查，例如：
  • GPU 型號（只要 A100，不要 V100）
  • 記憶體大小（80GB 版本才行）
  • MIG profile 或 NVLink 拓撲
• 如果是一次要跑 8 個 Pod 的 gang job，可以在 PreFilter 階段就判斷「叢集裡湊不齊 8 張卡」，直接拒絕，避免浪費。

這樣做的好處：

1. Fail fast：開發者立刻得到正確訊息，不必等 scheduler 慢慢測試所有 Node。
2. 更好的使用者體驗：錯誤訊息可以更精準，例如「需要 2 張 A100-80GB，但叢集只有 V100」。
3. 策略管控：可以加上租戶配額（某個 team 最多只能用 8 張 GPU），這是預設 scheduler 不會管的。
4. 效能更佳：在大型叢集裡，可以減少 scheduler 無謂的計算負擔。

小結

Kubernetes 預設的 scheduler 對大多數應用已經很好用，但在某些情境下，我們需要更進階的控制與更好的錯誤回饋。

• Extension Points：讓我們可以插入自訂邏輯，避免重寫整個 scheduler。
• Scheduler Profiles：讓一個叢集同時支援不同類型的 workload。
• GPU 案例：清楚展示了 PreFilter 的價值，從 fail-fast、策略管控到叢集資源最佳化，都比單純依賴 default scheduler 更好。

對於一般使用者，可能永遠只會用到 default-scheduler；但對於需要 AI/HPC、多租戶或合規需求 的場景，Scheduler Profiles 就是必備的工具。